Unattended Installations

The following explains how to run the installer in unattended command line mode with pre-determined options.

BEWARE: Care should be taken that all options are correct as the unattended mode provides little or no feedback about errors in the installation process.

General Syntax

Installations

Windows

In a command line with administrative rights:

Path-to-installer\PyramidInstaller.EXE –-mode unattended –-optionfile path-to-file\optionfile.ini

Linux

In a terminal session:

sudo /path-to-installer/PyramidInstaller.RUN –-mode unattended –-optionfile /path-to-file/optionafile.ini

Upgrades

If the install is launched on a machine that has a current Pyramid installation, an upgrade installation will be performed. Upgrades can also be run unattended.

If installing in unattended mode, then the same installation options file must be used as the original installation, with the addition of 2 extra fields (see below). Alternatively, the upgrade can be completed with a separate options file with the 2 required fields.

Using different settings in the options file will throw errors or produce unreliable results.

Un-installations

The syntax is like the installation. However, there is no options section.

Path-to-Pyramid-installation\uninstall.exe –-mode unattended

Options File Structure

The option file should contain all the “switches” needed to complete the installer. The switches should be saved to a file.

Each switch should have its setting name on the left and the setting value on the right. Each setting should be on its own row. For example

Linux

install-location=/opt/Pyramid data-location=/opt/Pyramid/repository

Windows

install-location=c:\program files\Pyramid data-location =c:\program files\Pyramid\repository

Install Option Settings

Switches

General
  • install-location – the main installation directory
  • data-location – the location for data and content
  • installation-type – Set the type of server installation. Use:
  • 0 for a single server install
  • 1 for a custom installation (where specific features are selectively installed). If you select 1, you must enumerate any deselected components using the switch disable-components. If you select 0, you can ignore the disable-components switch.
    • disable-components - a comma delimited list of components that will NOT be installed. The choices are explained in the next section below on “Components”.
Database Repositories
  • repositoryChoice– a choice to determine how to install the database repository. If the 'remote' options are used, the following settings must be set, as well as all the related details for connecting to the specified database instance.
    • Use “newlocal” to specify that a standalone, internal version of PostgreSQL should be used. (default option)
    • Use “newremote” to specify that an ‘external’ version of PostgreSQL, MS SQL Server or Oracle should be used. The selectNewRepository setting below must be set if using this option and specific settings for the database and server must be supplied.
    • Use “currentremote” to specify that a CURRENT ‘external’ version of PostgreSQL, MS SQL Server or Oracle should be re-used. This is required in a multi-server, cluster deployment, where the repository has already been setup. The selectCurrentRepository setting below must be set if using this option and specific settings for the database and server must be supplied.
  • selectNewRepository – specify the type of new remote database to use. This must be set if repositoryChoice was set to “newremote”. Use:
    • 0 for PostgreSQL
    • 1 for MS SQL
    • 3 for Oracle
  • selectCurrentRepository – specify the type of current remote database to use. This must be set if repositoryChoice was set to “currentremote”.
    • 0 for PostgreSQL
    • 1 for MS SQL
    • 3 for Oracle
Database Settings

These are not required if the internal, local PostgreSQL option was selected for repositoryChoice.

  • PostgreSQL: These switches are required if a remote PostgreSQL database was chosen.
    • postgreSqlHost - PostgreSQL Host Server Name
    • postgreSqlPort - PostgreSQL Port (standard port is usually 5432)
    • postgreSqlDb - PostgreSQL Database Name to create or connect to
    • postgreSqlUsername - PostgreSQL User Name
    • postgreSqlUserPassword - PostgreSQL User Password
    • pgLocation - indication of whether this is a native installation or one hosted in the cloud (RDS). See below.
  • Microsoft SQL Server: These switches are required if a remote MS SQL database was chosen
    • mssqlHost- MS SQL Host Server Name (with instance if relevant)
    • mssqlPort- MS SQL Port (standard port is usually 1433)
    • mssqlDb- MS SQL Database Name to create or connect to
    • mssqlUsername- MS SQL User Name
    • mssqlUserPassword- MS SQL User Password
    • msLocation - indication of whether this is a native installation or one hosted in the cloud (RDS), See below.
  • Oracle: These switches are required if a remote Oracle database was chosen. Note that Oracle requires a separate system user account to operate.
    • oracleHost- Oracle Host Server Name
    • oraclePort- Oracle Port (standard port is usually 1521)
    • oracleSysUsername- Oracle System User Name
    • oracleSysPassword- Oracle System User Password
    • oracleService- Oracle Service Name
    • oracleUsername- Oracle User Name (or Schema) to create
    • oracleUserPassword- Oracle User Password
    • orLocation - indication of whether this is a native installation or one hosted in the cloud (RDS), See below.
Database Locations

For each database type above, the installer needs to know the location type of the database to optimize the deployment. The choices are:

  • 0 - Native Installation (default option)
  • 1 - RDS installation on Amazon AWS
  • 2 - RDS installation on Microsoft Azure

Note: If the RDS option is used, the database needs to be provisioned in the relevant cloud platform BEFORE the installation is launched.

Web Server Type (Windows Only)
  • webServerOption – selects whether to deploy the internal web server only or the internal server with IIS. This switch must NOT be used in Linux option files.
    • Use webinternal for the internal engine only. This is the only option on Linux servers
    • Use webiis to deploy with Microsoft IIS Web Server on a Windows server. iisHostHeader setting below must be set if webiis is used.
  • iisHostHeader – specify the host header URL without HTTP or HTTPS. Required if webServerOption is set to webiis (e.g. “www.mysite.com”)
Initial User Settings

The next 2 settings are required for both single server (self-contained) and multi-server installs.

  • initUserName -The username for the initial user. Make sure it does not contain spaces and uses only standard characters and digits.
  • initUserPassword – this is the initial password for the initial user in the system. Make sure it does not contain spaces and uses only standard characters and digits.

Components

All components are selected by default. If you choose a custom install (installation-type=1), you can supply the list of disabled components that will NOT be installed

Windows Component Names

  • windesktop – standalone desktop client
  • winrte – Runtime Engine Server
  • winte – Task Engine Server
  • winrtr – Router Server
  • winws – Web Server
  • windnc – Windows Connector Server
  • winimdb – In-Memory Database Server

Example:

disable-components=winrte,winte,windnc

This will NOT install the runtime engine, task engine and the windows connector

Linux Component Names

  • linrte – Runtime Engine Server
  • linte – Task Engine Server
  • linrtr – Router Server
  • linws – Web Server
  • linimdb – In-Memory Database Server

Example:

disable-components=linrtr,linws

This will NOT install the router and web server

Upgrade Option Settings

Administrative User Settings

The 2 settings are required if the system is being upgraded in a single server. They are also required in a multi-server upgrade if the current installation enables the cluster to become “viable” (i.e. the cluster has at least one router, web server and run time engine).

  • adminUserName -The username for an administrative user in Pyramid. Make sure it does not contain spaces and uses only standard characters and digits.
  • adminUserPassword – The password for the admin user. Make sure it does not contain spaces and uses only standard characters and digits.

Challenges

  • Option settings should be well vetted and checked before installation. There is almost no feedback during an unattended installation. So errors will not be exposed to the installing user. In the event of error, the installer log file can be found in the installing user’s temp directory.
  • In Windows, Dotnet 4.5.2 is required. The installer will install Dotnet if required, but this will require a reboot of the server before the installer can continue. Unfortunately, the feedback about the reboot is not provided in unattended mode – except by reviewing the installer log. To avoid this situation, have Dotnet installed before launching the installer in unattended mode.
  • In Linux, it is best not to use directories, server names, database names, user ID’s or passwords with spaces in them. In some situations, they are acceptable. However, it is hard to pre-validate all the options in unattended mode. So they should be avoided.

Unattended Examples

Example 1 – Simple Install

This standard install option file deploys everything to a single Windows server, using the internal PostgreSQL repository and the internal web server engine only

install-location=E:\Program Files\Pyramid data-location=E:\Program Files\Pyramid\repository installation-type=0 repositoryChoice=newlocal webServerOption=webinternal initUserName=admin initUserPassword=5432

Example 2 – Advanced Install in Linux

This custom install option file deploys all components EXCEPT the Task Engine Server to a Linux machine. It uses a new remote PostgreSQL repository hosted on a machine called “MyDbServer” - using the AWS RDS framework. Uses the internal web server only.

install-location=/opt/pyramid data-location=/opt/pyramid/repository installation-type=1 disable-components=linte repositoryChoice=newremote selectNewRepository=0 pgLocation=1 postgreSqlHost=MyDbServer postgreSqlPort=5432 postgreSqlDb=px316 postgreSqlUsername=sa postgreSqlUserPassword=abc123 initUserName=admin initUserPassword=4321

Example 3 – Advanced Install to MS SQL

This custom install option file deploys all components EXCEPT the Task Engine Server and Desktop Client to a Windows machine. It uses a new remote MS SQL repository hosted on a machine called “My-pc”. It also uses IIS with a site address of “analytics.mysite.com”.

install-location=E:\Program Files\Pyramid data-location=E:\Program Files\Pyramid\repo installation-type=1 disable-components=winte, windesktop repositoryChoice=newremote selectNewRepository=1 mssqlHost=My-pc mssqlPort=1433 mssqlDb=px316 mssqlUsername=sa mssqlUserPassword=def456 webServerOption=webiis iisHostHeader=analytics.mysite.com initUserName=admin initUserPassword=4567